Present day computers comprise bus systems, onto which different devices may be plugged. More specifically, a bus system is often comprised of a bus controller and of a bus connected to the memory controller. Different devices may be connected to the bus, so as to be accessed by the bus controller.
One example of such buses is the DRAM bus designed by Rambus Inc. This bus is used for managing high speed DRAM devices. FIG. 1 is a schematic view of the architecture of this type of bus. It shows the memory controller 1, and the Rambus Channel 2. Several Direct Rambus DRAMs or Direct RDRams (trademark) 3-6 are connected to the Rambus Channel. As shown on FIG. 1, the memory controller as well as each of the RDRAMs comprises a Rambus interface 8 for using the bus. The bus 2 is terminated at one end by terminations, and is also connected to a reference voltage Vref as well as to a 400 MHz bus clock.
According to the Rambus specification, there is also provided a power down mode; it is contemplated in the specification that the power down mode is used for reducing power consumption, notably in portable computers.
Rambus products sold on the market are organised in Rambus RIMM (trademark) memory modules, each module supporting 4, 6, 8, 12 or 16 Direct RDRAMs devices. RIMM modules are compatible with standard motherboard form factors; a motherboard usually supports up to three module sockets. The Direct Rambus Channel signals are daisy chained through each module. See Rambus RIMM Module Preliminary Information, document DL0078 available from Rambus Inc.
There is also provided in the Rambus specification a SPD (Serial Presence Detect) device. The purpose of the SPD is to store and provide sufficient information for a system to initialise the memory subsystem correctly: the SPD is a ROM device provided on each RIMM module, which includes information relating to the DRAM timing and device parameters, core organisation, module parameters, and other system level information. The SPD EEPROM devices of each RIMM module conform to the I2C wire protocol, and may be read into or written into by the memory controller of a Rambus system. See Direct Rambus SPD Specification 1.0, available from Rambus Inc.
FIG. 2 is another view of a physical Rambus architecture, this time in an invalid configuration; it shows the memory controller 1 and the Direct Rambus Channel 2. Three modules 10-12 are connected to the bus; each side of each module may have up to 8 RDRAM devices, referenced again 3-6 on FIG. 2. Reference 13 is the SPD EEPROM of module 10; reference 14 shows the I2C protocol bus used by the memory controller for accessing the SPD EEPROMs of the different modules.
More details on Rambus may be found in the corresponding specification, issued by Rambus Inc. under the title Direct Rambus Technology Disclosure, Oct. 15, 1997.
One problem with Rambus is that the load of the bus is limited to 3 modules, and to 32 Direct RDRAM devices; if one of these limitations is violated, the bus system is not designed to be operational, and or even to boot at all; a computer in which the bus system is installed would in this case not be able to boot either.
This limitation on the number of modules is not likely in practice to be violated, since the bus normally comprises at most three module slots, and usually 2 or 3 module slots. However, a module may comprise up to 16 devices, so that the number of devices on the bus may exceed the highest allowable number of devices. This is the case in the configuration shown in FIG. 2.
Thus, the configuration of the bus hardware is such as to enable the bus to be improperly configured; in this case, a physical layer configuration constraint on the bus can be violated, and proper electrical operation of the bus is therefore not ensured. This can prevent the bus as a whole from booting properly. This possibility makes the system difficult for the user to upgrade or to diagnose problems that occur when they try to.
A variety of bus configuration problems have been addressed in other contexts and a variety of solutions prosposed.
For instance, U.S. Pat. No. 5,550,990 discusses physical partitioning of logically continuous buses. This document is directed to the SCSI (Small Computer System Interface) bus architecture, and suggests partitioning the bus into two or more physical entities which to the computer appear as one logical entity. This allows addressing problems potentially arising because of the scope of the architecture to be resolved; one example of such problems is excessive signal degradation due to use of signal rates which although allowed by the architecture are inappropriate for a particular bus loading. The solution disclosed in this document is to provide on the bus an adapter; instead of ensuring physical continuity of the bus, the adapter separates the bus into two bus partitions. This makes it possible, e.g. to operate the two partitions of the bus at different speeds, or to increase the number of devices connected to the bus. Where the speed has to be determined, a negotiation between the adapter and the devices connected to the bus is carried out at the time the adapter is initialised.
U.S. Pat. No. 5,870,571 discusses automatic control of data transfer rates over a computer bus; this document is particularly directed to UltraSCSI buses. This document suggests detecting whether a SCSI external device is connected to the bus, and if this is the case, inhibiting the host adapter in order to reduce the data transfer rates to SCSI rate; otherwise, if no external SCSI device is detected, the UltraSCSI rate may be used, and the host adapter is not inhibited. In this document, the adapter polls the devices connected to the bus at initialisation, in order to know the transfer rate at which they may operate. Note that the operation of devices connected to the bus is not modified, since the host adapter only is inhibited.
U.S. Pat. No. 5,237,690 discusses configuration at boot of IBM PS/2 personal computers. These computers provide a POS (programmable option select) for defining or providing settings for the assignment of system resources to a system board and various adapters. In order to avoid having to reconfigure the computer each time an adapter is added, removed or changed, this document suggests testing at boot of the computer whether any adapter was added, removed or changed; if this is the case, the adapters that were altered are disabled, and the computer is operated with all other adapters.
U.S. Pat. No. 5,797,032 discusses a bus for connecting extension cards to a data processing system, and more particularly and ISA or EISA bus. For addressing the problem of collisions between the addresses of the different cards, this document suggests enabling all cards one at a time, for testing the addresses to which they respond. The cards that generate collisions are then disabled, and a message is displayed on a monitor for indicating to the user which cards were disabled.
The configuration constraints with which these two latter documents are concerned are logical-layer constraints and to resolve associated configuration problems the systems described rely on the buses concerned operating correctly at the physical level.